|
Anyone trying to develop a modeling environment within their organization has been faced with many competing demands. The demands come from those responsible for establishing architectural guidance for the organization, the industry standard frameworks that are designed to assist in establishing the architectural direction, the features provided by the available toolsets in this space, and those who are impacted by the architectural direction as they attempt to do their daily work.
Frameworks come in three "flavors." "Framework" with an upper case "F" refers to industry standards such as TOGAF and Archimate. They represent the knowledge of experts within the domain of the Framework and help ensure you are on an accepted track. On the other hand, "framework" with a lower case "f" refers to a framework developed by the using organization to create a modeling environment that provides a means to ensure the models developed across the organization are complete, consistent, concise, and comprehensible. The third flavor is a combination of the two. In this case, an industry standard is embellished to fit within the organization's culture.
There are heated debates about which architectural framework, if any, is the best for any given situation. The problem is that one size does not fit all. Many standards are large, complex, and difficult to implement. They often do not address everyday situations your modeling teams face while trying to deliver complete, concise, and consistent models. Unfortunately, you are often locked into the paradigm provided the toolset and your teams begin to question the need for a framework in the first place.
A good modeling framework should be flexible enough to adapt to your particular environment. It should not dictate the use of specific terms, nor adamantly demand that you assemble components and relationships in a certain manner. However, once you have adapted the framework to your needs, it should provide the level of governance that you desire to place over your modeling teams. The framework should not only allow you to make changes to it as your experience grows, it should also automatically update your models to reflect those changes. Most importantly, a good framework should make your team’s work easier to do, not harder.
To show the value of a good framework, let us look at an analogy from a completely different domain, photography.
Taking great pictures is both an art and a science. The underlying premise of photography comes down to the length of the exposure time (speed) and the size of the aperture opening. This seems simple enough. However, as anyone can tell you, taking great pictures requires an in-depth understanding of the subtleties of light and composition. The advent of cameras with automated metering helped the amateur take good photographs under average conditions. However, those cameras and the photo enthusiasts holding them often did not understand that, for example, a scene consisting of white snow has to be overexposed or the snow will appear a dingy gray in the resulting picture.
The next evolutionary step in photography was “smart cameras” programmed to adjust the exposure time and aperture according to the type of scene you are shooting. Set the camera on “Snow” and it will automatically overexpose the photograph by the correct amount. Set it for “Backlight”, “Sports”, or “Night” and the camera sets the exposure and speed accordingly, even turning on the flash if needed. The camera manufacturers have embedded the knowledge of the experts regarding the different scenes into the camera. Now, the amateur can simply select the appropriate scene, point, and shoot, and get a perfectly exposed photo. Of course, the photographer is still responsible for the composure of the picture, hopefully not cutting off Aunt Janet’s head!
Instead of dealing with time and aperture settings, the world of formal modeling deals with the much more complex concepts that UML has been designed to address. The decision process for the different “scenes” in modeling, therefore, is much more difficult than in our photography analogy. This makes the need for “smart modeling environments” all the more important. |
